Si necesitamos posicionar un sitio web que fue desarrollado utilizando algún framework de javascript podríamos encontrarnos con que Google no lo indexa (muestra) como nosotros desearíamos y esto mismo pasa con cualquier otro buscador como Bing o incluso con las redes sociales (Facebook, Twitter, Instagram, Linkedin, etc) al momento de compartir contenidos. ¿Por qué? La razón es simple, el sitio no “imprime” su código y por ende los robots de los buscadores o de las redes sociales no pueden leerlo.
¿A que nos referimos con “imprimir” cuando hablamos de sitios web?
Si tenemos que estudiar para la facultad, y nuestro profesor nos manda el material por email, tranquilamente podemos leer el material desde la computadora pero muchos de nosotros quizá prefiramos imprimir el material para leerlo en cualquier lugar sin necesidad de prender la computadora. Algo similar sucede con Google y los sitios web.
Cuando le informamos al buscador que nuestro sitio existe o incluso si lo descubre por su cuenta, esa url que representa nuestro sitio va a añadirse a una lista de urls para analizar y cuando nos toque el momento un “Robot”, que no es mas que un visitante de nuestro sitio solo que en lugar de ser una persona es una computadora que abre nuestra página y “lee” nuestro código fuente, obtiene la información que está presente y la analiza, mas o menos como la analizaríamos nosotros si fuera un apunte de la facu; busca las ideas principales, extrae los conceptos mas importantes y los almacena de una forma ordenada los términos que le “disparen” recuerdos, al momento de rendir el examen.
Para un buscador el momento de “rendir el examen” es cuando una persona realiza una pregunta (búsqueda) y de repente se encuentra con la respuesta justo ahí enfrente de sus ojos y en una cuestión de milésimas de segundos.
Ahora que sabemos como estudia Google, ¿Por qué no se acuerda de nuestro sitio? La respuesta a esta pregunta ya la sabemos “el sitio no imprime su código”.
¿Cómo hacemos para imprimir el código de nuestro sitio y facilitarle el estudio a Google?
Para responder a esta pregunta primero debemos saber cual es la diferencia entre un sitio tradicional que “imprime” su código y uno desarrollado con algún framework de javascript (Angular, React, Vue, etc) que no lo hace.
Los primeros sitios web o como dijimos los “tradicionales”, consistían en una serie de archivos con extensión “.html” dentro del cual cada uno tenía determinada información utilizando las etiquetas de marcado html como ser <p> (párrafos), <h1> (títulos), <h2> (subtítulos) o <a> (links), entre otras. Esta marcación del contenido es la forma impresa en la que Google prefiere estudiar.
Estructura simple de un sitio tradicional
| /inicio.html | /nosotros.html | /contacto.html |
| Bienvenidos a nuestro Sitio | Somos la agencia SEO líder a nivel regional | Escribinos! |
| <p>Bienvenidos a nuestro Sitio</p> | <h1>Somos la agencia SEO líder a nivel regional</h1> | <h2>Escribinos!</h2> <p><a href=»https://www.linkedin.com/company/punto-rojo-marketing»> Linkedin</a></p> <p><a href=»https://www.facebook.com/PuntoRojoMarketing»> Facebook</a></p> <p> <a href=»https://twitter.com/PuntoRojoM»> Twitter</a></p> |
Hace ya mucho, los sitios y aplicaciones web comienzan a incorporar a su código fuente (HTML), algunos fragmentos de código en javascript (JS) para mejorar la interactividad con el usuario y cargar o enviar contenido mediante la comunicación con servidores sin necesidad de recargar el navegador, lo que mejora la velocidad de navegación y la usabilidad del sitio por parte de los visitantes. De un tiempo a esta parte la proporción entre código HTML y JS ha comenzado a cambiar y podíamos ver cada vez mas y mas fragmentos JS en los sitios web hasta que aparecieron los ahora famosísimos frameworks de javascript que han casi eliminado el contenido HTML en el código fuente de los sitios web, asemejándose a una página en blanco.
Estructura simplificada de un sitio javascript
| /inicio | /nosotros | /contacto |
| Bienvenidos a nuestro Sitio | Somos la agencia SEO líder a nivel regional | Escribinos! |
| <div id=“app”></div> | <div id=“app”></div> | <div id=“app”></div> |
Podrás notar que en el caso de la estructura simplificada de nuestro sitio javascript, el código fuente es exactamente el mismo para las 3 páginas pero sin embargo en pantalla vemos contenido distinto. A esto nos referimos cuando decimos que nuestro contenido no esta impreso y a Google le cuesta leerlo.
Para entender mejor debemos conocer algunos conceptos mas:
- Reproducción por el lado del Cliente (CSR – Client Side Rendering): Permite a los desarrolladores hacer que sus sitios web estén completamente renderizados en el navegador utilizando JavaScript en lugar de tener una página HTML diferente por ruta (url), un sitio web CSR crea cada ruta de forma dinámica directamente en el navegador utilizando los recursos del mismo para la obtención remota de los contenidos haciendo peticiones a un servidor de datos y la velocidad de navegación en el sitio es realmente mucho mejor.
- Reproducción por el lado del Servidor (SSR – Server Side Rendering): Permite a los desarrolladores rellenar previamente una página web con contenido directamente en el servidor mostrándose en el navegador; pero este solo imprime, no ejecuta ningún javascript para mostrar contenido.
Como Google y demás robots prefieren estudiar nuestro sitio desde la impresión, tenemos que lograr que nuestro sitio javascript también “imprima”.
Para eso podemos hacer un “pre-render” de cada una de las urls del sitio y entonces cuando ingresamos a esas urls el servidor nos devuelve el contenido pre-impreso y luego el navegador le da soporte haciendo los requerimientos nuevos directo al servidor mediante otro tipo de petición de datos.
De esta forma incluso se puede hacer mas rápida la carga inicial del sitio, Google puede leer el código y el usuario “común” puede luego disfrutar de las grandes ventajas de un sitio JS.
Pero… ¿Qué pasa si nuestro sitio tiene datos que cambian constantemente?
Tendríamos nuestras pre-impresiones todo el tiempo desactualizadas y por ende Google no sabría dar las respuestas correctas en sus exámenes. Bueno… así es como tenemos que ir un poco mas allá e implementar SSR.
Para el caso de los sitios en JS el SSR podría decirse que es “algo como” procesar el sitio, como si el servidor fuera un cliente (Chrome, Firefox, Safari, Edge – nuevo Internet Explorer, Opera, etc); no vamos a entrar en las especificaciones técnicas porque no es el objetivo de este artículo, esto implica un diseño arquitectónico mas complejo de nuestra aplicación, pero nos va a garantizar que nuestro sitio esté siempre IMPRESO y que el contenido esté siempre ACTUALIZADO.
Tenemos que aclarar que si nuestro sitio no tiene cambios periódicos, con un pre-render es mas que suficiente para aparecer en las mejores posiciones de los buscadores y aportar a las personas que buscan el mejor y mas actualizado contenido.
Conclusión
JavaScript SEO es básicamente la práctica de asegurarse de que el contenido de una página (ejecutado a través de JS) se represente correctamente, se indexe y finalmente se clasifique en los resultados de los motores de búsqueda.
Una startup o cualquier empresa, ya sea pyme, negocio local o una gran multinacional busca siempre vender más; sea para salir al mercado, para crecer o incluso superar una crisis. El acceso a nuevas vidrieras y mercados resulta fundamental para lograr el gran objetivo de vender más productos o servicios.
Hoy mostrarse en internet se hace cada vez mas fácil, pero hacerlo bien es el verdadero desafío. Ser inteligente y aprovechar lo que internet nos ofrece implica algo más que crear un WordPress, una página Wix o un blogspot. Hacerlo bien hace la diferencia!!!
Maru Amallo
linkedin.com/in/maruamallo/
